Computer displays typically are constructed in a manner to display text and other video information in a landscape mode. There have been, of course, some displays that are constructed to display video data in portrait mode. To bridge the gap between the two modes of displays, some have built software drivers to enable a display to be rotated between landscape and portrait mode (i.e. typically 90, 180, or 270 degrees) and then to hit a software switch (either automatically or under user-controlled input) in order to render the image “right-side up”. Badger, in U.S. Pat. No. 5,973,664, describes such a prior software system that enables the mapping of pixel information from one mode to the other—and hence, enables a rotatable display for desired user control.
Badger describes his system succinctly in FIGS. 1, 2 and 3. FIG. 1 illustrates the modification of an image before it is sent to a rotated computer display. Computer display 100A is oriented in standard landscape mode, displaying an image which is taller than it is wide. The space on either side of the image is wasted. The user of rotatable display 100A can rotate it 90 degrees clockwise, which would result in computer display 100B. The image on display 100B appears rotated 90 degrees, however, because of the rotation of the display. In order to view the image upright as on rotated display 100C, the computer compensates for the clockwise rotation of the display by sending to the display an image which is rotated 90 degrees in the counterclockwise direction. The image sent by the computer to display 100C would look like that on display 100D if the display were left in the standard landscape orientation.
An illustrative embodiment of Badger's system is shown in FIG. 2. Computer display 216 exhibits image 218 based on display image information 210 stored in display memory 212, which is accessible by computer 220. This display memory 212 is organized into arrays of memory cells, and the organization of information in display memory 212 takes the form of contiguous blocks of memory which each represent a single horizontal line of pixels on the display. Video hardware 214 uses display image information 210 in display memory 212 to generate display signals for computer display 216. The appearance of image 218 on computer display 216 is determined by the organization of information 210 placed in display memory 212. When software application 200, such as a word processor or a drawing program, needs to put an image 204 on display screen 216, it typically places image information 204 in source memory 202. Application 200 then signals operating system 206 that image 204 in source memory 202 needs to be put on display screen 216. Operating system 206 then communicates this information to driver 208. Driver 208 is a small software program which performs the task of retrieving source image information 204 from source memory 202 and putting it into display memory 212. If any modifications to the orientation of image 204 are necessary, driver 208 performs these modifications while writing display image information 210 to display memory 212. Driver 208 performs all modifications to image 204 using a single parameterized method of operation that can be used to rotate image 204 for any of a number of orientation modes.
Referring now to FIG. 3, image 210 to be shown on computer display 216 is in the form of an array of display image lines 306, with each display image line 306 being an array of pixels 308. Driver 208 transfers image 204 line by line, pixel by pixel from source memory 202 to display memory 212. Computer display 216 shows what is in display memory 212, and driver 208 can change the orientation of displayed image 218 by changing the ordering of pixels 308 of image 210 in display memory 212. In FIG. 3, an image of an arrow is shown in source memory 202. Display memory 212 contains an image of the same arrow rotated counterclockwise 90 degrees. The mapping of pixels 304 from source memory 202 to display memory 212 is illustrated by the three pixels marked A, B, and C, which are mapped to the three pixels 308 marked A′, B′, and C′.
When a user wishes to change the orientation of images 218 on computer display 216, the user makes a selection of one of a variety of possible orientation modes. When this selection occurs, driver 208 is notified, and a setup procedure begins so that images 218 later drawn to computer display 216 will have the desired orientation. This setup procedure involves using information about the desired orientation to calculate two increment parameters, X.sub.—Increment and Y.sub.—Increment. The X.sub.—Increment parameter indicates the difference in display memory 212 between pixels 308 which correspond to adjacent pixels 304 of the same source image line 302 in source memory 202. For example, pixels A and B are adjacent pixels 304 of the same source image line 302 in FIG. 3. For display image 210, the values of these two pixels 304 are transferred to A′ and B′ in display memory 212. The difference in memory addresses between A′ and B′ in display memory 212 is the X.sub.—Increment parameter. The Y.sub.—Increment parameter is the difference in display memory 212 between pixels 308 which correspond to adjacent pixels 304 of different source image lines 302 in source memory 202. For display image 210, pixels A′ and C′ correspond to pixels A and C of source memory 202, A and C being adjacent pixels 304 of different source image lines 302 in source memory 202. The difference in memory addresses between A′ and C′ in display memory 212 is the Y.sub.—Increment parameter.
When driver 208 is notified that image 204 is to be displayed on computer display 216, driver 208 invokes a set of software instructions to transfer image information 204 from source memory 202 into display memory 212 using the X.sub.—Increment and Y.sub.—Increment parameters, which are modified depending on the desired orientation mode. As each pixel 304 in a source image line 302 is transferred from source memory 202 to display memory 212, driver 208 determines the new pixel 308 location in display memory 212 by adding the X.sub.—Increment parameter to the location of the previous pixel 308 from that source image line 302. Each time a new source image line 302 is begun, the Y.sub.—Increment parameter is added to the location in display memory 212 of the first pixel 308 of the previous source image line 302. After the location in display memory 212 of the first pixel is determined, the location in display memory 212 of each subsequent pixel can be determined from the two increment parameters. In this way, the same set of instructions can effect the transfer of image information 204 regardless of which orientation mode selected, merely by changing the values of the X.sub.—Increment and Y.sub.—Increment parameters according to the selected orientation mode.
As useful as the Badger's system is (as depicted in FIGS. 1, 2 and 3) and while it is clearly desirable to have such user-flexibility in a display, the main limitation to the system disclosed by Badger is that the mapping takes places at the pixel-level—and no finer level of mapping is described. Today's displays are taking advantage of sub-pixel rendering—methods and apparatus that allow for a finer resolution of video data (in particular, text). In fact, both Microsoft and Adobe have methods that allow for sub-pixel rendering using the traditional RGB stripe.
Part of the problem is that prior art displays (particularly those relying on the RGB stripe) suffer from a non-rotationally symmetrical Nyquist limit, addressability, and/or MTF response curve. When images are rotated on a display that is non-symmetrical, the direction that has the least performance limits the image quality as the image component requiring greater performance passes through that angle.
For example, many, if not most, western text (Latin & Cyrillic) have more high spatial frequency components in the horizontal than the vertical direction. These high spatial frequencies are spread over a range of frequencies and phases. On a display with fixed square pixels, only certain high spatial frequencies and phases can be displayed. On a prior art RGB Stripe panel, display sub-pixel rendering offers higher addressability, thus allowing higher spatial frequencies to have a greater range of phases, but only in the direction normal to the stripes. Thus fonts are best rendered using sub-pixel rendering with the stripes aligned vertically, in line with the majority of long strokes of most of the characters. Displays conventionally meet this requirement when the lines of text are aligned horizontally along the long axis of typical flat panel displays in the so called “landscape” orientation. But when the lines of text are aligned with the short axis, and the display physically rotated to the so called “portrait” orientation, desired to allow display of full pages of text, as they are usually printed on paper in the “portrait” orientation, the stripes are normal to the long strokes. Since sub-pixel rendering only increases the addressability normal to the stripes, the conventionally oriented striped panel is suboptimal for use in sub-pixel rendering text in the portrait orientation, as the text requires greater addressability in the ‘wrong’ axis.
For this reason, the stripes should be aligned vertically in portrait mode. This requires that the display be designated for use as a portrait display only. But many displays would benefit from the ability to be used in both modes. Many advantageous uses would abound—e.g. a flat panel monitor on a support that allows the user to rotate the display between portrait orientation for word processing and landscape orientation for other work; a so-called “tablet computer” or “Personal Digital Assistant” (“PDA”) that allows the user to read an electronically stored book in portrait orientation and turn it to view it in landscape orientation to view a calendar. Thus, it is highly desirable to have a display that allows equal sub-pixel rendering performance in both portrait and landscape orientations.
For some uses of flat panels, images are rotated at any or even all angles. One such use is for navigation aids in automobiles and handheld devices such as Geo Positioning System (GPS) enabled map displays. As the car or user changes orientation with respect to the terrain, the map rotates in the counter direction on the display to keep the relative orientation of the displayed map image aligned with the terrain. On prior art displays, such as the RGB Stripe display, conventional whole pixel rendering allows higher spatial frequencies in the diagonal directions. Images that are rotated on the display change quality depending on whether the high spatial frequencies are in alignment with the diagonals or not. Thus, an image, such as a map, seems to shift in appearance (and, potentially, usability) as the image is rotated. Thus, it is highly desirable to have a display that has equal performance in any and all orientations. That is to say, its Nyquist Limit, addressability, and/or MTF response curves are equal in all directions. If these response functions were plotted for such a display, they would from a circle with the center at zero spatial frequency—as will be discussed in greater detail below.
The family of display architectures—disclosed in the commonly owned U.S. patent application Ser. No. 09/916,232, published as U.S. Patent Application Publication No. 2002/0015110 A1, and, now issued as U.S. Pat. No. 6,903,754, to Candice Hellen Brown Elliott, entitled “ARRANGEMENT OF COLOR PIXELS FOR FULL COLOR IMAGING DEVICES WITH SIMPLIFIED ADDRESSING,” and known under the trademark name PENTILE™—all share the common trait of a red and green sub-pixel checkerboard upon which luminance information is mapped using sub-pixel rendering. When these displays sub-pixel render images that are rotated about, the image quality and appearance remains substantially constant due to the symmetrical nature of the red and green sub-pixel checkerboard layout and the filter response of the sub-pixel rendering algorithms. If the Nyquist Limit, addressability, and/or MTF response curves are plotted for these display architectures, it is found that they are circles with the center at zero spatial frequency.
Since a display with a circular response has equal performance in all direction, it follows that it must also have equal performance in landscape and portrait orientations.
In addition to the problems mentioned above regarding the quality of text when sub-pixel rendered on said RGB Stripe displays, another problem occurs when the prior art RGB stripe sub-pixel rendering methods are followed by a pixel-to-pixel rotational mapping, such as e.g. taught by Badger. Typically, as is often attempted in commercial use, the sub-pixel rendering of text is performed by the operating system, and the screen image rotation and/or mirror performed by a ‘driver’ afterwards. The problem arises when the text rendering code assumes that the sub-pixel stripes are aligned normal to the line of text (aligned with the tall stems of Western fonts). The sub-pixel rendered data is then remapped, improperly, by the screen rotation method such as taught by Badger, which has as an internal assumption, that the data is conventional, non-sub-pixel rendered data. That is to say that each red, green, and blue data point per pixel represent a color sample that is coincident. In sub-pixel rendered data, this assumption is false. When rotated by the Badger method, the sub-pixel rendering is “scrambled”.